今天要聊的是 Jeff Patton 和Peter Economy 寫的 User Story Mapping，中文譯名是使用者故事對照。

今天要聊的是其中在講使用者故事得部分，我認爲這是最基本也是最核心的，這個懂了，才能進一步聊 User Story Mapping。

良好的故事對話關係到人與為什麼，而不只是故事內容。
透過故事去思考「誰」「為什麼」「需要」
在讀這本書之前，我已經知道什麼是 User Story 了，但只停留在表面。我之前就是那種認為 User Story 就是把需求用簡單的形式寫出來，去表明利益關係人是誰，基於怎樣的需求，想要什麼樣的東西，然後搭配 Acceptance Critera 去確認怎樣算做完。所以我在前公司，很更重 User Story 有沒有寫好，然後在意大家有沒有暸解到那三個元素。

使用者故事得名於它們應如何被應用，而不是什麼應該被寫下來
到這邊其實也並沒有錯，但卻稍為停留表層。但我卻常常期望每一張 Asana 上面的項目，都會寫得很詳細，這其實就有點走偏了。事實上我應該更重視大家透過使用者故事展開對話，然後去多聊這個故事的人與為什麼，建立共同理解，而不是冀望在文字本身。

分享文件不是分享共同理解
因為就算是同一段文字，每個人解讀的都可能不同。若太依賴文字，那就會造成我講的是 A，但你以為我在說 B，於是兩個人就依據各自的理解去實作或者驗收了。

交談並記錄，在述說故事時撰寫卡片或便利貼具象化你們的想法
我們應該一起交流，最好是有白板，把自己腦海的畫面畫出來，搭配文字去豐富整個使用者故事，最後把它拍下來。

為了幫助記憶，將你們的對話用照片或影片記錄下來
我在現在的公司，我們就很依賴這樣的做法，大家聽完 PO 講完數個故事，也大致釐清後，再認領這些故事去提煉，思考我們該怎麼提供解決方案，這個解決方案長什麼樣子，需 怎麼驗收，將想法都寫在白板上，最後拍照上傳到專案管理服務中。

好的文件就像是度假照片
之後我們會在 Planning 時分享這些曾經提煉過的項目，然後看著我們整理好的文字與拍的照片，就像是看度假照片一樣，回想起當初我們在提煉時的討論，再一一向沒參與到提煉的人分享——就如同和夥伴們聊聊當初我們去度假時，如何如何的，期望能幫助他們暸解到更多照片上沒有的資訊。

運用使用者故事的真正目標是達成共同理解
因此我們透過這些方法，嘗試建立起我們對這些 User Story 共同的理解，儘管我們並不一定會達成共識，但是我們會想起我們曾經的討論，然後朝著當時決定的共同理解去實作解決方案，已滿做我們使用者的需求。